An operating device can include hardware components and/or software components which in principle can also be used simultaneously by different computer-based units or clients.
If, for example, data is modified in the course of the access (e.g. by way of a WRITE access), it is important to ensure that the data is kept consistent.
It is known in the prior art to set what are called exclusive locks in order to ensure data consistency during contending accesses to operating device/module. The exclusive locks are managed by way of a central server which usually also controls storage of and access to the resources. Within this scheme, if a client wishes to access a resource, it is mandatory that it receives an exclusive lock in order thereupon to be able to access the resource (e.g. for writing).
By allocating the exclusive lock it is ensured that only the requesting client can access the operating device/module, thereby preventing the possibility of inconsistent data records being generated if another client were to want to access the same resource simultaneously or in an overlapping time interval. A write access to data records of a memory resource serves as a typical example of an access to a resource.
Normally it is ensured that only one exclusive lock may be allocated per resource at a given time instant to one client exclusively. Since a read access by definition does not modify the data, multiple concurrent accesses may be permitted without an exclusive lock having to be allocated each time.
Depending on operating system or implementation it may however be that a read access is likewise allocated a lock, albeit not an exclusive lock, but a non-exclusive lock. The system of allocating locks in order to ensure consistent data storage and management is implemented so that concurrent accesses are serialized according to a strict sequentialization scheme.
A fundamental disadvantage of systems from the prior art that operate with the allocation of exclusive locks is, however, to be seen in the fact that they oblige significant performance penalties to be accepted, since the requesting clients basically have to wait for the exclusive locks to be allocated or released. Furthermore it may happen that exclusive locks are “lost” because an exclusive lock is not released due to errors elsewhere. Nonetheless, the concept of exclusive locks is an extensively used operating system device/module for controlling accesses to data records (such as e.g. text documents or the like), countable resources (such as e.g. memory space, input/output channels, etc.) or other resources that are managed on a computerized basis (such as e.g. hotel bookings, car rentals, flight reservations or production facilities of logistical units, etc.).
Two strategies in particular are employed for this in the prior art:
1.—“Many Early Locks”:
                This strategy entails an approach whereby an exclusive lock is already set at a very early stage and in all those situations in which there is basically the possibility that data records will be modified. With this approach an exclusive lock is usually set regardless of the type of access (e.g. read access, write access, execute access, etc.) to the data records. The disadvantage of this approach is to be seen in the fact that a client potentially has to wait a very long time before it receives a non-critical read access to the contents of requested data records. Accordingly, with this approach, more importance is attached to maintaining the consistency of the data than on processing speed.2.—“Lock Little, Lock Late”:        With this strategy it is attempted to set exclusive locks as little as possible and as late as possible. Normally an exclusive lock is set on a data record that is being processed by a client only when the client also actually wishes to modify the contents of the data record. The disadvantage of this approach is that another client simply wanting to perform a read access to the data will possibly see an out-of-date (inconsistent) data record for which, namely, another client in parallel possesses an exclusive lock for modifying the respective data. This approach favors the speed aspect above the consistency aspect.        
In critical systems (e.g. traffic control systems in which maintaining the consistency of the data plays a particularly important role) the former of the two above-cited strategies (“many early locks”) is more often chosen on safety grounds alone. In non-critical applications and when asynchronous protocols such as e.g. the internet are used, the second “lock little—lock late” strategy is employed more often in order to be able to provide a system delivering the highest possible performance.